The present invention relates to a telecommunications apparatus, system and method; in particular, but not exclusively, to a system for managing telephone call set-up and in-call functions irrespective of the type of underlying network.
Telephony systems and services are ubiquitous, and are used for both residential and business purposes. The services and features provided by telephony systems have developed from simple person-to-person calls, to conference calls where many parties are connected together at a time. Telephony terminal devices have developed beyond the simple telephone to incorporate many features such as an address book of telephone numbers and quick dial telephone numbers, typically under microprocessor control. Examples of telephony devices are regular fixed line handsets (an illustrative example of which is the “Duet 60” Corded Phone sold by BT pic), more sophisticated fixed line telephony terminals (an illustrative example of which is the Meridian M3904 Professional Telephone sold by Nortel Networks), mobile/cellular handsets, mobile/cellular enabled personal digital assistants (PDAs) and other mobile/cellular terminals, or Internet Protocol (IP) telephones.
More sophisticated features are often required by businesses, and such features may be supplied by a Private Automatic Branch Exchange (PABX), also referred to as a Private Branch Exchange (PBX), which is installed at business premises for running an internal telephony system and interfacing to an external telephone system, for example a Public Switched Telephone Network (PSTN).
An example of a conventional telephony system is illustrated schematically in FIG. 1. The conventional telephone system is based on circuit switched connections which establish an “end-to-end” connection between parties to a call. The core of the telephone system is the Public Switched Telephone Network (PSTN) 2. Individual telephone terminals 4,6 may be connected to the PSTN 2 by local exchanges (not shown). Cellular telephone systems such as the Global System for Mobile devices (GSM) may also be connected to the PSTN 2 by way of a Mobile Switching Center (MSC) 8. Telephone calls from a cellular telephone (or more generally mobile terminal) 10 to a telephone terminal 4,6 connected to the PSTN 2 are routed through a base station 12 to a MSC 8, and then into the PSTN 2 for example for connection with a telephone terminal 4,6.
Many businesses operate a PABX 16 which provides enhanced telephony features for the telephones 14 of their internal telephony network, and may also provide call conferencing features with external telephones 4, 6, 10. Each PABX 16 has a fixed number of telephone lines 18 providing communication to the PSTN 2, and if the PABX 16 provides conference call features it also comprises one or more so-called “call bridge modules” 20. Each call bridge module provides call connections between a fixed number of lines, typically 3 or 5 parties.
Telephone calls need not be made over the circuit switched PSTN 2, but may use packet switched technology and be sent over an Internet 22 using an Internet Protocol communications format provided the PABX 16 has a Voice over Internet Protocol (VoIP) module 24. VoIP calls are directed over the Internet 22, for example to an IP endpoint 26 such as an Internet enabled telephone or a computer system having a software client providing telephony functions.
If facilities for linking more than 3 or 5 parties to a conference call are required, then typically the only way to provide this additional functionality is to add more bridge modules 20 to the PABX 16. Each bridge module 20 represents a cost to the business, and if large conference call facilities are only required occasionally then a number of the bridge modules 20 purchased to provide large call conferencing facilities would remain unused for much of the time. This represents a significant waste of resources.
Furthermore, as the number of external parties to a call is limited by the number of outside lines 18 supported by the PABX 16 and the cost of a PABX depends on the number of external lines it has to handle, provision for conferencing a large number of external parties via the PABX 16 requires a significant capital investment for functionality that may only be used occasionally.
Telephone handsets 14 may also limit the number of parties that can join in a call. Advanced handsets may allow multiple call conferencing, but some are limited to 3-way calling or do not support conference call features at all. Typically such multi-way call conferencing has a highly restricted and awkward user interface. For example, in simple 3-way calling it is necessary to first call a party, wait until they have been connected, park that call, call a second party and then connect the calls together. For more than 3-way calling connecting all the parties to the call can be a particularly laborious and time-consuming process. Furthermore, each supplier of handsets and/or PABXs often have multiple, and non-standard, complex function button or key strokes for conferencing in additional parties to an ongoing call. This mitigates against multi-party impromptu call conferencing.
Manual dialling of numbers not yet programmed into a handset or telephony device address book or speed dial system also mitigates against ad-hoc multi-party conference calls, and telephone calling in general. Furthermore, the more features a handset 14 has, the greater the cost of the handset which is wasted if the handset is primarily used for simple 2-way calling. Additionally, with conventional PABX/handset controlled call conferencing the initiator (leader) of a call cannot drop a particular party (call leg) without dropping the whole call. This means that whilst an individual conference call participant can be asked to leave a conference call, the call leader cannot establish that they have actually done as requested. Consequently, a party may continue to listen into a conversation even after they have been asked to leave.
Another drawback is that different service providers may be used for setting up scheduled conference calls, where invitees “dial-in” to the conference call at the scheduled time. Thus, different protocols and telephone numbers have to be used to set up the conference calls.
The number of telephone numbers stored by a telephone handset, whether or not a conventional handset 4, 6, 14, is often limited—particularly when compared to the number that can be stored in a cellular telephone 10. Additionally, address books are often on Personal Digital Assistants (PDAs) and in desktop applications such as Contacts in Microsoft® Outlook. The PDA, which sometimes includes a cellular telephone, is generally kept with a user at all times and often has the most up-to-date address/telephone number information. Synchronising a cellular telephone with a PDA or Outlook, then ensures that the cellular telephone is up-to-date.
An artefact of the foregoing is that a cellular telephone 10 user will often call direct from their cellular telephone, even when at their desk with a land line telephone to hand, due to the convenience of having their telephone numbers stored in the address book, and being able to dial directly from them. However, cellular telephone calls are generally more costly than landline calls and this habit of cellular phone users leads to increased telephony expenses either for the business, or for the user in their personal capacity.
This problem is further exacerbated by the fact that many landline telephone handsets do not have telephone address book functionality, and those which do are generally limited to just a few telephone numbers, for example 10, and further require programming with the desired numbers even though those numbers may already be stored in the user's cellular telephone, PDA or desktop address book applications.
GB 2320641 has previously proposed to provide an internet-connected PC to send a call-initiation message via the internet to a service provider's web server, which then instructs a PSTN switch to make a call over the PSTN to the user's PSTN handset. When the user answers, the PSTN switch then calls the destination PSTN number and when that is answered, the PSTN switch joins the two call legs together. It has also previously been proposed to add further PSTN legs to the call and bridge them within the PSTN switch.
Whilst such a system provides the user with call conferencing functionality, and enables the user to take advantage of lower cost networks, a number of significant problems exist. For example, in such a system the functionality of the system as a whole is limited by the functionality of the PSTN switch and the interface by means of which the user communicates with the switch. Typically control mechanisms are html web pages (or so-called ‘thin’ clients running within browsers), email messages or SMS messages. Such control mechanisms require the use of an intermediary server to translate requests from these interfaces into a protocol understandable by the PSTN switch. In such an architecture the level of control and responsiveness of calls is limited. Moreover, such control mechanisms do not consist of independent software running on the operating system of the user's control device and consequently cannot interface with other programs running on the user's control device to provide enhanced functionality and usability.
Other systems have previously proposed to mix different legs of calls in a two-party or multi-party or conference call in software within an IP environment instead of in hardware resident on a PSTN switch. A current illustrative example of such an arrangement is eDial's Advanced Communications Server™, although we do not know when this server was first made available to the public.
Such systems, whilst mitigating some of the problems outlined above, are problematic because such switches are expensive (both in financial terms, and in terms of the resources required to install and maintain them). As a consequence, such switches tend only to be sold to large enterprises who can afford the equipment and are capable of implementing the solution, managing it and supporting it as it operates within their existing IT structure. A consequence of such solutions is that they are not best suited to the residential or small-medium sized business.
It is also well known in the art to use a software program (called a Telephony Application Programming Interface or TAPI) to connect a PC running an application within the Microsoft Windows operating system to telephone services. TAPI was introduced in 1993 as the result of joint development by Microsoft and Intel. The standard supports connections by individual computers as well as LAN connections serving many computers. Within each connection type, TAPI defines standards for simple call control and for manipulating call content.
Problems with TAPI are that a TAPI has to be created for each application and therefore requires separate installation or download by the user of a TAPI for each application that the user requires. Their operation can also be different from application to application depending on the creator. Additionally, TAPI based programs only provide the interface between the program running on the PC and some external communication service rather than a complete communication solution.
In an attempt to gain cost savings and take advantage of the benefits offered by carrying voice over IP networks (VoIP) instead of the PSTN, it has previously been proposed to provide a hardware plug-in that converts the PSTN voice signal from a user's telephone into a digital, packetised signal that then is fed into the user's broadband internet connection. Vonage provide one such hardware plug-in, although again we do not know whether this plug-in was available to the public before the filing of this application.
Problems with such systems include having to insert an extra piece of hardware into the user's network, requiring extra expense, configuration expertise and cabling. A major limitation is that calls over the service can only be made using the phone connected to the hardware plug-in. As the voice can only go through the internet, if the user's internet connection is of inconsistent quality, the quality of their call suffers and if they lose their internet connection, they lose the call. Moreover, such solutions typically contemplate replicating the functionality of the PSTN at lower cost rather than introducing new features and functionality to improve productivity and usability.
A further previously proposed alternative is that of the so-called “softphone”. The most common type of softphone is a software client residing on a user's PC and which must have both microphone and speaker functionality, or external equivalents connected to the PC. The user then communicates through the PC purely over VoIP. Skype and Vonage each currently offer a VoIP phone, although again we do not know whether these phones were available before the filing date of the present application.
Problems include that the user is limited to talking through their PC. The PC is required to run the compression and decompression protocols (CODEC) of the software and as a result voice quality may be impacted if the computer is processing other CPU intensive tasks during a conversation. If their internet connection is of inconsistent quality, the quality of their call suffers. If they lose their internet connection, they lose the call. In addition, these solutions are not handset independent—the connection of the call-leg to the call originator must be to the PC, not for example to a PSTN or cellular or mobile telephone of the originator's choosing. PCs are poorly configured as telephones and require extensive configuration to balance ear and microphone volume for comfortable communication.